home *** CD-ROM | disk | FTP | other *** search
- Path: solon.com!not-for-mail
- From: seebs@solutions.solon.com (Peter Seebach)
- Newsgroups: comp.lang.c
- Subject: Re: #include --> Question
- Date: 29 Feb 1996 12:54:50 -0600
- Organization: Usenet Fact Police (Undercover)
- Message-ID: <4h4spq$c68@solutions.solon.com>
- References: <4gvp2c$sdr$1@mhafc.production.compuserve.com> <4h1d2l$4n3@pyrrhus-f.hrz.tu-chemnitz.de> <4h2si8$1bf@solutions.solon.com> <31359A05.4014@iadfw.net>
- NNTP-Posting-Host: solutions.solon.com
-
- In article <31359A05.4014@iadfw.net>, Larry Weiss <lfw@iadfw.net> wrote:
- >Peter Seebach wrote:
- >> The character '\' introduces undefined behavior in a header file name.
-
- >Peter, are you sure about this? Can you cite a clause of the Standard?
-
- >I'm looking at Clause 6.8.2 and 6.1.7. The only characters that cannot be
- >used in a #include "name" header name according to those sections are
- >newline and doublequote.
-
- (Because all of the relevant quoting characters are being discussed, I will
- use q for quotes.)
-
- Ahh, but you must also read the paragraph below that (also 6.1.7), which
- states that if the characters q'q, q\q, or q/*q occur between the q"q
- delimiters, the behavior is undefined. (Between q<q and q>q, q"q also
- introduces undefined behavior.)
-
- There's a footnote (25) attached to this - "Thus, sequences of characters that
- resemble esqape sequences cause undefined behavior."
-
- (Yes, footnotes are not binding, but the conclusion is obviously valid.)
-
- I object slightly to using /* as a "character", but no big complaints.
-
- >Of course, all interpretation of the characters used to signify a
- > #include "name" are implementation defined.
-
- Yes.
-
- -s
- --
- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
- C/Unix wizard -- C/Unix questions? Send mail for help. No, really!
- FUCK the communications decency act. Goddamned government. [literally.]
- The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
-